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DETAILED ACTION 
Examiner's Response to Applicant's Remarks 

1 . Applicant's arguments submitted on 08/16/2004 with respect to claims 1-30 have 
been reconsidered but are not deemed persuasive for the reasons set forth below. 

Examiner's Responses to Applicant's Remarks are listed below: 

2. Applicant argues (under REMARKS section) that, Heistermann et al. does not 
teach "associating an attribute version identifier with an attribute in the set of attributes 
such that each attribute in the set of attributes is associated with an attribute version 
identifier." 

Examiner respectfully disagrees. Heistermann teaches associating an attribute 

Version identifier (i.e. "Step 121 identifies the properties for this program object version that should be 
included in the serialized representation of the program object. " ... "In any case, an implementation of a process 
that determines the properties to serialize may be considered a function of the program object class and version. 
Step 122 ascertains the value of each property to serialize and step 130 generates serial information that conveys 
the program object class and version, and a representation of each respective property that was identified in steps 
121 and 122. 99 ... "If this object-descriptor base class, the process continues with step 133 that writes to the serial 
information stream an identification of the version pertaining to the base class. The process continues by serializing 
the appropriate properties of that base class. "; The preceding text excerpts clearly indicate that when an object is 
serialized, the corresponding class version identifier is also serialized. With the serialization of the object, the 
properties or attributes also have to be identified to be serialized so that the object can be de-serialized and recreated 
later. But the corresponding class for the object can be inherited from a base class. In that case the object is going to 
inherit attributes from the base class. The inherited attributes or properties will have to be identified differently. 
Some of the attributes can be serialize-able objects themselves. Therefore, Heistermann says that the 
identifications of the attributes/properties are a function of the program object class and version. Let us say 
that the class version of the program object is X2, which is inherited from the base class whose version is X 1 . The 
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properties/attributes of program object class are identified as y2=f(x2) and the properties inherited from the base 
class to the inherited program object class is yl=f(xl). Therefore each attribute in the set of attributes for the 
program object class is either associated with f(xl) or f(x2) identifiers. The applicant never claims that the 
attribute/property identifier may not be associated with the class version identifier.) (col 6, lines 38-53; col 7, lines 
35-46) With an attribute (i.e. a property) (col 6, lines 38-53; col 7, lines 35-46) in the Set Of 
attributes (i.e. a set of properties of a class) (col 6, lines 38-53; col 7, lines 35-46) SUCh that each 

attribute in the set of attributes is associated with an attribute version identifier 

(i.e., Heistermann says that the identifications of the attributes/properties are a function of the program 
object class and version. Let us say that the class version of the program object is X2, which is inherited from the 
base class whose version is XI. The properties/attributes of program object class are identified as y2=f(x2) and the 
properties inherited from the base class to the inherited program object class is yl=f{xl). Therefore each attribute in 
the set of attributes for the program object class is either associated with f(xl) or f(x2) identifiers. The applicant 
never claims that the attribute/property identifier may not be associated with the class version identifier.) (col 6, 
lines 38-53; col 7, lines 35-46). 

Any other arguments by the applicant are more limiting than the claimed 
language. 

3. Applicant is inaccurate for the reasons explicitly stated in the First Office Action. 
Examiner asserts that the Heistermann teaches Applicant's invention. 

4. These reasons have been explicitly stated in the First Office Action. Please see 
the next section. 
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Claim Rejections - 35 USC § 102 

5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351 (a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

6. Claims 1-8, 14-21, and 27-29 are rejected under 35 U.S.C. 102(e) as being 
anticipated by Heistermann et al. (U.S. Patent No. 6,477,701 and Heistermann 
hereinafter). 

As to claim 1, Heistermann teaches a method for object-oriented management of 

Serializable Objects (i.e. serializing and de-serializing program objects) (col 3, lines 1-22), the method 
Comprising: identifying an Object (i.e. "Step 101 instantiates a program object of this class and step 110 
invokes the appropriate method to obtain an identification of the program object version. ") (col 6, lines 35-40), 

wherein the object comprises a set of attributes (i.e. properties) (col 6, lines 32-53); associating 

a claSS Version identifier With the Object (i.e. "For each respective program object to serialize, step 132 
writes into the serial information stream an identification of the class of the respective program object and step J 33 
writes an identification of the version of the respective program object. ") (col 6, lines 54-62), wherein the 

class version identifier identifies the object as an instance of a specific version of a class 

(i.e. "Step 101 instantiates a program object of this class and step 110 invokes the appropriate method to obtain an 
identification of the program object version. ") (col 6, lines 35-40); and associating an attribute version 
identifier (i.e. "Step 121 identifies the properties for this program object version that should be included in the 
serialized representation of the program object " ... "In any case, an implementation of a process that determines 
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the properties to serialize may be considered a function of the program object class and version. Step 122 
ascertains the value of each property to serialize and step 130 generates serial information that conveys the 
program object class and version, and a representation of each respective property that was identified in steps 121 
and 122. 99 ... "If this object-descriptor base class, the process continues with step 133 that writes to the serial 
information stream an identification of the version pertaining to the base class. The process continues by serializing 
the appropriate properties of that base class. "; The preceding text excerpts clearly indicate that when an object is 
serialized, the corresponding class version identifier is also serialized. With the serialization of the object, the 
properties or attributes also have to be identified to be serialized so that the object can be de-serialized and recreated 
later. But the corresponding class for the object can be inherited from a base class. In that case the object is going to 
inherit attributes from the base class. The inherited attributes or properties will have to be identified differently. 
Some of the attributes can be serialize-able objects themselves. Therefore, Heistermann says that the 
identifications of the attributes/properties are a function of the program object class and version. Let us say 
that the class version of the program object is X2, which is inherited from the base class whose version is XI. The 
properties/attributes of program object class are identified as y2=f(x2) and the properties inherited from the base 
class to the inherited program object class is yl=f(xl). Therefore each attribute in the set of attributes for the 
program object class is either associated with f(xl) or f(x2) identifiers. The applicant never claims that the 
attribute/property identifier may not be associated with the class version identifier.) (col 6, lines 38-53; col 7, lines 
35-46) With an attribute (i.e. a property) (col 6, lines 38-53; col 7, lines 35-46) in the Set of attributes 
(i.e. a set of properties of a class) (col 6, lines 38-53; col 7, lines 35-46) SUCh that each attribute in the Set 

of attributes is associated with an attribute version identifier. 

As to claim 2, Heistermann teaches that an attribute version identifier (i.e. the 

properties version identifier is a function of the program object class and version. The property identifier 
corresponds to the version of the class it belongs to or was declared in.) (col 6, lines 38-53) represents an 
instance Of a Specific Version Of a ClaSS (i.e. "In any case, an implementation of a process that 
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determines the properties to serialize may be considered a Junction of the program object class and version.) (col 6, 

lines 38-53) in which the associated attribute was initially declared within the class (i.e. "in 

any case, an implementation of a process that determines the properties to serialize may be considered a function of 
the program object class and version. Step 122 ascertains the value of each property to serialize and step 130 
generates serial information that conveys the program object class and version, and a representation of each 
respective property that was identified in steps 121 and 122. "; i.e. the properties version identifier is a function of 
the program object class and version. The property identifier corresponds to the version of the class it belongs to or 
was declared in.) (col 6, lines 38-53). 

As to claim 3, Heistermann teaches writing a data stream (i.e. serial stream of 

information) (col 6, lines 38-53) representing an Object Serialization (i.e. "According to this process, 
step 131 writes the number of program objects to serialize into a serial stream of information. ") (col 6, lines 54-62) 

of the object (col 6, lines 38-53), wherein the data stream (col 6, lines 38-53) comprises the 

ClaSS version identifier Of the Object (i.e. "Step Wl instantiates a program object of this class and step 
110 invokes the appropriate method to obtain an identification of the program object version. ") (col 6, lines 35-40), 

an attribute value (i.e. the properties value) (col 6, lines 38-53) for an attribute in the set of 
attributes (i.e. the properties of the object) (col 6, lines 38-53), and an attribute version identifier for 

an attribute in the Set Of attributes (i.e. "In any case, an implementation of a process that determines the 
properties to serialize may be considered a function of the program object class and version. Step 122 ascertains the 
value of each property to serialize and step 130 generates serial information that conveys the program object class 
and version, and a representation of each respective property that was identified in steps 121 and 122. ") (col 6, 
lines 38-53). 
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As to claim 4, Heistermann teaches writing a class identifier (i.e. "String className = 
in.readUTFO; " ) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67); and instantiating the object in 
accordance with the class identifier (i.e. 

"private Object deserializeObject(ObjectInputStream in) { 
String className ~ in.readUTFQ; //Read object class name; 
obj = objClass.newInstanceQ; 

... " ) (Fig. 4; col ii, lines 1-25; col 14, lines 37-67) for the class of the object into the data 

Stream (i.e. "According to the illustrated format, segment 301 provides an indication of the number of program 
objects represented by information in the stream, segments 302 and 303 provide an indication of the class name and 
version of the first program object represented in the stream, respectively, and segment 304 conveys serial 
information representing one or more properties of the first program object. ") (col 8, lines 15-24). 

As to claim 5, Heistermann teaches writing an attribute count (i.e. props, lengtK) (col 11, 

lines 1-25; col 14, lines 37-67) indicating B number Of attributes (i.e. properties) (col 11, lines 1-25; col 

14, lines 37-67) from the set of attributes that were written into the data stream (i.e. 

"private void serializeObject(ObjectOutputStream out, Xserializable obj){ 

Property Descriptor [] props = descriptor. getProperties (version); 
For (int j=0;j< props. length; j++) { ... " 



"private Object deserializeObject(ObjectInputStream in) { 
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Property Descriptor [] props = objDesc.getPropertiesfversion); 

for (int j=0;j< props.length;j++) { ... "; i.e. the above code excerpts shows that the properties 
count/length is also stored in the stream. The de-serialization method retrieves the properties count from the stream 
passed in the method parameter.) (col 1 1, lines 1-25; col 14, lines 37-67). 

As to claim 6, Heistermann teaches reading a data stream (i.e. serial stream of 
information) (col 6, lines 38-53) representing a serialized object (i.e. 

"private void serializeObject(ObjectOutputStr earn out, Xserializable obj){... 

out.writeObject(retVal); //Write object"; i.e. the above code excerpts shows the serialization of a object) 

(col ii, lines i-25; col 14, lines 37-67), wherein the data stream (col 6, lines 38-53) comprises a 

Serialized ClaSS Version identifier (i.e. "For each respective program object to serialize, step 132 writes 
into the serial information stream an identification of the class of the respective program object and step 133 writes 
an identification of the version of the respective program object ") (col 6, lines 54-62), a Set of Serialized 

attribute values (i.e. properties values) (col ii, lines 1-25; col 14, lines 37-67), and a set of serialized 

attribute Version identifiers (i.e. the properties version identifier is a function of the program object class and 
version. The property identifier corresponds to the version of the class it belongs to or was declared in.) (col 6, lines 

38-53), wherein serialized attribute version identifiers (col 6, lines 38-53) in the set of 
serialized attribute version identifiers (col 6, lines 38-53) are paired with serialized attribute 
values (i.e. properties values) (col ii, lines 1-25; col 14, lines 37-67) in the set of serialized attribute 
values ( i.e. 

"private Object deserializeObjectfObjectlnputStream in) { 
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float version = in.readFloatf); 

PropertDescriptorfJ props = obj Desc.getProperties (version); 
for (int j=0;j< props. length ; j++) { 
propVal = deserializeObject(in); 
return obj; 

} "; i.e. the above code excerpts shows that the de-serialization method gets the data stream as the input 
parameter. From the stream the method retrieves the class version and associated properties/attributes 
version. Then the method goes on retrieving the property value. Therefore the properties version and values 
are stored in the same place i.e. block 304 in Fig. 4) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67). 

As to claim 7, Heistermann teaches reading a class identifier (i.e. the class name) (Fig. 

4; col 1 1, lines 1-25; col 14, lines 37-67) for the serialized Object (i.e. Obj ectlnputStr earn) (Fig. 4; col 11, 
lines 1-25; col 14, lines 37-67) from the data Stream (i.e. 

"private Object deserializeObject(Obj ectlnputStr earn in) { 

String className = in.readUTFO; //Read object class name; 

... " ) (Fig. 4; col ii, lines 1-25; col 14, lines 37-67); and instantiating the object in 
accordance with the class identifier (i.e. 

"private Object deserializeObject(Obj ectlnputStr earn in) { 
String className = in.readUTFO; //Read object class name; 
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obj = objClass.newInstanceO; ... " ) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67), wherein the ClaSS 
Version identifier (i.e. "For each respective program object to serialize, step 132 writes into the serial 
information stream an identification of the class of the respective program object and step 133 writes an 
identification of the version of the respective program object. ") (col 6, lines 54-62) Of the Object and the 

serialized class version identifier (col 6, lines 54-62) of the serialized object (i.e. 

ObjectlnputStream) (Fig. 4; col 11, lines 1-25; col 14, lines 37-67) may differ (i.e. 
"private Object deserializeObjectfObjectlnputStream in) { 

String className = in.readUTFQ; //Read object class name- 
Class objClass = Class forName(desc.getClassName()); 

obj = objClass.newInstanceO; ... " ; i.e. the above code excerpts shows that the new object is instantiated 
by just using the class name, which is retrieved from the input data stream; At this point the new instance of the 
object is not aware of the class version of the serialized object and therefore may very well differ from the serialized 
class version.) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67). 

As to claim 8, Heistermann teaches reading an attribute count (i.e. props.iength) (Fig. 

4; col 11, lines 1-25; col 14, lines 37-67) for the Set Of Serialized attribute values (properties values) 
(Fig. 4; col 11, lines 1-25; col 14, lines 37-67) from the data Stream (i.e. serial stream of information) (col 6, 
lines 38-53), 

As to claim 14, Heistermann teaches a computer program product on a computer 
readable medium for use in a data processing system for object-oriented management 
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t 

Of serializable Objects (i.e. serializing and de-serializing program objects) (col 3, lines 1-22), the 

computer program product comprising: instructions for identifying an object (i.e. "Step 101 

instantiates a program object of this class and step 110 invokes the appropriate method to obtain an identification of 

the program object version. ") (col 6, lines 35-40), wherein the object comprises a set of attributes 
(i.e. properties) (col 6, lines 32-53); instructions for associating a class version identifier (i.e. "For 

each respective program object to serialize, step 132 writes into the serial information stream an identification of 
the class of the respective program object and step 133 writes an identification of the version of the respective 
program object. ") (col 6, lines 54-62) With the Object (i.e. "For each respective program object to serialize, 
step 132 writes into the serial information stream an identification of the class of the respective program object and 
step 133 writes an identification of the version of the respective program object ") (col 6, lines 54-62), wherein 
the ClaSS version identifier (i.e. "For each respective program object to serialize, step 132 writes into the 
serial information stream an identification of the class of the respective program object and step 1 33 writes an 
identification of the version of the respective program object ") (col 6, lines 54-62) identifies the Object as 
an instance Of a Specific Version Of a ClaSS (i.e. "Step Wl instantiates a program object of this class 
and step 110 invokes the appropriate method to obtain an identification of the program object version. ") (col 6, 

lines 35-40); and instructions for associating an attribute version identifier (i.e. (( step 121 

identifies the properties for this program object version that should be included in the serialized representation of 
the program object " ... "In any case, an implementation of a process that determines the properties to serialize 
may be considered a function of the program object class and version. Step 122 ascertains the value of each 
property to serialize and step 130 generates serial information that conveys the program object class and version, 
and a representation of each respective property that was identified in steps 121 and 122. " ... "If this object- 
descriptor base class, the process continues with step 133 that writes to the serial information stream an 
identification of the version pertaining to the base class. The process continues by serializing the appropriate 
properties of that base class. "; The preceding text excerpts clearly indicate that when an object is serialized, the 
corresponding class version identifier is also serialized. With the serialization of the object, the properties or 
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attributes also have to be identified to be serialized so that the object can be de-serialized and recreated later. But the 
corresponding class for the object can be inherited from a base class. In that case the object is going to inherit 
attributes from the base class. The inherited attributes or properties will have to be identified differently. Some of 
the attributes can be serialize-able objects themselves. Therefore, Heistermann says that the identifications of the 
attributes/properties are a function of the program object class and version. Let us say that the class version of 
the program object is X2, which is inherited from the base class whose version is XI. The properties/attributes of 
program object class are identified as y2=f(x2) and the properties inherited from the base class to the inherited 
program object class is yl=f(xl). Therefore each attribute in the set of attributes for the program object class is 
either associated with f(xl) or f(x2) identifiers. The applicant never claims that the attribute/property identifier may 
not be associated with the class version identifier.) (col 6, lines 38-53; col 7, lines 35-46) with an attribute (i.e. 
a property) (col 6, lines 38-53; col 7, lines 35-46) in the Set Of attributes (i.e. a set of properties of a class) 

(col 6, lines 38-53; col 7, lines 35-46) such that each attribute in the set of attributes is 
associated with an attribute version identifier. 

As to claim 15, Heistermann teaches that an attribute version identifier (i.e. the 

properties version identifier is a function of the program object class and version. The property identifier 
corresponds to the version of the class it belongs to or was declared in.) (col 6, lines 38-53) represents an 
instance Of a Specific Version Of a ClaSS (i.e. "For each respective program object to serialize, step 132 
writes into the serial information stream an identification of the class of the respective program object and step 133 
writes an identification of the version of the respective program object. ") (col 6, lines 54-62) in Which the 

associated attribute (col 6, lines 38-53; col 7, lines 35-46) was initially declared (i.e. the 

attribute/property was declared in the class) (col 6, lines 38-53; col 7, lines 35-46) within the ClaSS (i.e. "In any 
case, an implementation of a process that determines the properties to serialize may be considered a function of the 
program object class and version. Step 122 ascertains the value of each property to serialize and step 130 generates 
serial information that conveys the program object class and version, and a representation of each respective 
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property that was identified in steps 121 and 122. "; i.e. the properties version identifier is a function of the program 
object class and version. The property identifier corresponds to the version of the class it belongs to or was declared 
in.) (col 6, lines 38-53). 

As to claim 16, Heistermann teaches instructions for writing a data stream (i.e. 
serial stream of information) (col 6, lines 38-53) representing an object serialization of the object 
(col 6, lines 38-53), wherein the data stream (col 6, lines 38-53) comprises the class version 

identifier (i.e. "For each respective program object to serialize, step 132 writes into the serial information stream 
an identification of the class of the respective program object and step 133 writes an identification of the version of 
the respective program object. ") (col 6, lines 54-62) Of the Object (i.e. "Step 101 instantiates a program object 
of this class and step 110 invokes the appropriate method to obtain an identification of the program object 
version. ") (col 6, lines 35-40), an attribute Value (i.e. the properties value) (col 6, lines 38-53) for an 

attribute in the set of attributes (i.e. the properties of the object) (col 6, lines 38-53), and an attribute 

Version identifier (i.e. "Step 121 identifies the properties for this program object version that should be 
included in the serialized representation of the program object. " ... "In any case, an implementation of a process 
that determines the properties to serialize may be considered a function of the program object class and version. 
Step 122 ascertains the value of each property to serialize and step 130 generates serial information that conveys 
the program object class and version, and a representation of each respective property that was identified in steps 
121 and 122. " ... "If this object-descriptor base class, the process continues with step 133 that writes to the serial 
information stream an identification of the version pertaining to the base class. The process continues by serializing 
the appropriate properties of that base class. "; i.e. whether the properties/attributes are from a child class or a base 
class they are the function of the program object class and version. Therefore properties from a child class object 
would have different identifier than the base class properties and both sets of properties would be serialized with 
different identifiers) (col 6, lines 38-53; col 7, lines 35-46) for an attribute in the Set of attributes (i.e. 
"In any case, an implementation of a process that determines the properties to serialize may be considered a 
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function of the program object class and version. Step 122 ascertains the value of each property to serialize and step 
130 generates serial information that conveys the program object class and version, and a representation of each 
respective property that was identified in steps 121 and 122. ") (col 6, lines 38-53). 

As to claim 17, Heistermann teaches instructions for writing a class identifier (i.e. 

the class name) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67) for the ClaSS Of the Object into the data 
Stream (i.e. "According to the illustrated format, segment 301 provides an indication of the number of program 
objects represented by information in the stream, segments 302 and 303 provide an indication of the class name and 
version of the first program object represented in the stream, respectively, and segment 304 conveys serial 
information representing one or more properties of the first program object. ") (col 8, lines 15-24), 

As to claim 18, Heistermann teaches instructions for writing an attribute count (i.e. 
props.iength) (col ii, lines 1-25; col 14, lines 37-67) indicating a number of attributes from the set of 
attributes that were written into the data stream (i.e. 

"private void serializeObject(ObjectOutputStream out, Xserializable obj){ 

PropertDescriptor[] props = descriptor. getProperties (version); 
For (intj=0;j< props.iength; j++) { ... " 

"private Object deserializeObjectfObjectlnputStream in) { 



PropertDescriptorfJ props = objDesc.getProperties(version); 
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for (int j=0;j< props. length; f ... "; i.e. the above code excerpts shows that the properties 
count/length is also stored in the stream. The de-serialization method retrieves the properties count from the stream 
passed in the method parameter.) (col 1 1, lines 1-25; col 14, lines 37-67). 

As to claim 19, Heistermann teaches instructions for reading a data stream (i.e. 

serial stream of information) (col 6, lines 38-53) representing a Serialized Object (i.e. 
"private void serializeObject(ObjectOutputStr earn out, Xserializable obj){... 

out.writeObjectfretVal); //Write object"; i.e. the above code excerpts shows the serialization of a object) 

(col 11, lines 1-25; col 14, lines 37-67), wherein the data stream (col 6, lines 38-53) comprises a 

Serialized ClaSS Version identifier (i.e. "For each respective program object to serialize, step 132 writes 
into the serial information stream an identification of the class of the respective program object and step 133 writes 
an identification of the version of the respective program object. ") (col 6, lines 54-62), a Set Of Serialized 

attribute values (i.e. properties values) (col ii, lines 1-25; col 14, lines 37-67), and a set of serialized 

attribute version identifiers (i.e. the properties version identifier is a function of the program object class and 
version. The property identifier corresponds to the version of the class it belongs to or was declared in.) (col 6, lines 

38-53), wherein serialized attribute version identifiers (col 6, lines 38-53) in the set of 
serialized attribute version identifiers (col 6, lines 38-53) are paired with serialized attribute 

values (i.e. properties values) (col 1 1, lines 1-25; col 14, lines 37-67) in the Set Of Serialized attribute 

values ( i.e. 

"private Object deserializeObject(ObjectlnputStream in) { 
float version = in.readFloatQ; 
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PropertDescriptorfJ props = objDesc.getProperties(version); 
for (int j=0;j< props, length; f 
propVal = deserializeObjectfin); 
return obj; 

} i.e. the above code excerpts shows that the de-serialization method gets the data stream as the input 
parameter. From the stream the method retrieves the class version and associated properties/attributes 
version. Then the method goes on retrieving the property value. Therefore the properties version and values 
are stored in the same place i.e. block 304 in Fig. 4) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67). 

As to claim 20, Heistermann teaches instructions for reading a class identifier (i.e. 

the class name) (Fig. 4; col 11, lines 1-25; col 14, lines 37-67) for the Serialized Object from the data 

stream (i.e. 

"private Object deserializeObject(ObjectInputStream in) { 

String className = in.readUTFQ; //Read object class name; ... "-) (Fig. 4; col 1 1, lines 1-25; col 14, lines 

37-67); and instructions for instantiating the object in accordance with the class identifier 

(i.e. "private Object deserializeObjectfObjectlnputStream in) { 



String className = in.readUTFQ; //Read object class name; 



Application/Control Number: 09/894,096 Page 1 7 

Art Unit: 2165 

obj = objClass.newInstanceQ; ... " ) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67), Wherein the Class 

version identifier of the object and the serialized class version identifier of the serialized 
object may differ (i.e. 

"private Object deserializeObject(ObjectlnputStream in) { 
String className - in.readUTFQ; //Read object class name; 
Class objClass = Class.forNamefdesc.getClassNameQ); 

obj = objClass.newlnstanceO; ... " ; i.e. the above code excerpts shows that the new object is instantiated 
by just using the class name, which is retrieved from the input data stream; At this point the new instance of the 
object is not aware of the class version of the serialized object and therefore may very well differ from the serialized 
class version.) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67). 

As to claim 21 , Heistermann teaches instructions for reading an attribute count 

(i.e. props.length) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67) for the Set Of Serialized attribute 
values from the data Stream (Fig. 4; col ll, lines 1-25; col 14, lines 37-67). 

As to claim 27, Heistermann teaches an apparatus for object-oriented 

management Of Serializable Objects (i.e. serializing and de-serializing program objects) (col 3, lines 1- 

22), the apparatus comprising: means for identifying an object (i.e. "Step 101 instantiates a 

program object of this class and step 110 invokes the appropriate method to obtain an identification of the program 

object version. ") (col 6, lines 35-40), wherein the object comprises a set of attributes (i.e. 
properties) (col 6, lines 32-53); means for associating a class version identifier with the object 

(i.e. "For each respective program object to serialize, step 132 writes into the serial information stream an 
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identification of the class of the respective program object and step 133 writes an identification of the version of the 

respective program object. ") (col 6, lines 54-62), wherein the class version identifier identifies the 

Object as an instance Of a Specific Version Of a ClaSS (i.e. "Step 101 instantiates a program object of 
this class and step 110 invokes the appropriate method to obtain an identification of the program object version. ") 

(col 6, lines 35-40); and means for associating an attribute version identifier (i.e. "Step 121 

identifies the properties for this program object version that should be included in the serialized representation of 
the program object 99 ... "In any case, an implementation of a process that determines the properties to serialize 
may be considered a function of the program object class and version. Step 122 ascertains the value of each 
property to serialize and step 130 generates serial information that conveys the program object class and version, 
and a representation of each respective property that was identified in steps 121 and 122. " ... "If this object- 
descriptor base class, the process continues with step 133 that writes to the serial information stream an 
identification of the version pertaining to the base class. The process continues by serializing the appropriate 
properties of that base class. The preceding text excerpts clearly indicate that when an object is serialized, the 
corresponding class version identifier is also serialized. With the serialization of the object, the properties or 
attributes also have to be identified to be serialized so that the object can be de-serialized and recreated later. But the 
corresponding class for the object can be a inherited from a base class. In that case the object is going to inherit 
attributes from the base class. The inherited attributes or properties will have to be identified differently. Some of 
the attributes can be serialize-able objects themselves. Therefore, Heistermann says that the identifications of the 
attributes/properties are a function of the program object class and version. Let us say that the class version of 
the program object is X2, which is inherited from the base class whose version is XI. The properties/attributes of 
program object class are identified as y2=f(x2) and the properties inherited from the base class to the inherited 
program object class is yl=f(xl). Therefore each attribute in the set of attributes for the program object class is 
either associated with f(xl) or f(x2) identifiers. The applicant never claims that the attribute/property identifier may 
not be associated with the class version identifier.) (col 6, lines 38-53; col 7, lines 35-46) with an attribute (i.e. 
a property) (col 6, lines 38-53; col 7, lines 35-46) in the Set of attributes (i.e. a set of properties of a class) 
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(col 6, lines 38-53; col 7, lines 35-46) such that each attribute in the set of attributes is 
associated with an attribute version identifier. 

As to claim 28, Heistermann teaches means for writing a data stream (i.e. serial 
stream of information) (col 6, lines 38-53) representing an object serialization of the object (col 6, 
lines 38-53), wherein the data stream comprises the class version identifier of the object 

(i.e. "Step 101 instantiates a program object of this class and step 110 invokes the appropriate method to obtain an 
identification of the program object version. ") (col 6, lines 35-40), an attribute Value (i.e. the properties value) 

(col 6, lines 38-53) for an attribute in the set of attributes, and an attribute version identifier 

for an attribute in the Set Of attributes (i.e. "In any case, an implementation of a process that determines 
the properties to serialize may be considered a function of the program object class and version. Step 122 ascertains 
the value of each property to serialize and step 130 generates serial information that conveys the program object 
class and version, and a representation of each respective property that was identified in steps 121 and 122. ") (col 
6, lines 38-53). 

As to claim 29, Heistermann teaches means for reading a data stream (i.e. serial 
stream of information) (col 6, lines 38-53) representing a serialized object (i.e. 

"private void serializeObjectfObjectOutputStream out, Xserializable obj){... 

out.writeObject(retVal); //Write object" ; i.e. the above code excerpts shows the serialization of a object) 

(col 11, lines 1-25; col 14, lines 37-67), wherein the data stream (col 6, lines 38-53) comprises a 

Serialized ClaSS Version identifier (i.e. "For each respective program object to serialize, step 132 writes 
into the serial information stream an identification of the class of the respective program object and step 133 writes 
an identification of the version of the respective program object. ") (col 6, lines 54-62), a Set of Serialized 



Application/Control Number: 09/894,096 Page 20 

Art Unit: 2165 

attribute values (i.e. properties values) (col ii, lines i-25; col 14, lines 37-67), and a set of serialized 

attribute Version identifiers (i.e. the properties version identifier is a function of the program object class and 
version. The property identifier corresponds to the version of the class it belongs to or was declared in.) (col 6, lines 

38-53), wherein serialized attribute version identifiers (col 6, lines 38-53) in the set of 
serialized attribute version identifiers (col 6, lines 38-53) are paired with serialized attribute 
values (i.e. properties values) (col ii, lines i-25; col 14, lines 37-67) in the set of serialized attribute 
values ( i.e. 

"private Object deserializeObject(ObjectInputStream in) { 
float version = in.readFloatQ; 

PropertDescriptorf] props = objDesc.getProperties(version); 
for (int j=0;j< props .length; { 
propVal = deserializeObject(in); 
return obj; 

} " ; Le. the above code excerpts shows that the de-serialization method gets the data stream as the input 
parameter. From the stream the method retrieves the class version and associated properties/attributes 
version. Then the method goes on retrieving the property value. Therefore the properties version and values 
are stored in the same place i.e. block 304 in Fig. 4) (Fig. 4; col 1 1, lines 1-25; col 14, lines 37-67). 



7. 



Allowable Subject Matter 

Claims 12-13,25-26 and 30 are allowed over the prior art of record. 
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As to claims 12-13,25-26 and 30, Heistermann does not disclose, teach or 
suggest the claimed limitations of (in combination with all other features in the claims), a 
method and associated system for providing backwards and forwards compatibility 
between different versions of serialized object data, which includes identifying an object, 
wherein the object comprises a set of attributes, wherein each attribute in the set of 
attributes is associated with a version identifier, and wherein the object is an instance of 
a first version of a class; writing a data stream representing serialization of the object's 
attributes and associated version identifiers; reading a data stream representing a 
serialized object into a new object instance of a second version of a class; and 
refraining from storing attributes from the data stream into the new object instance that 
are not represented in the new object instance while reading the data stream. 

8. Claims 9-1 1 and 22-24 are objected to as being dependent upon a rejected base 
claim, but would be allowable if rewritten in independent form including all of the 
limitations of the base claim and any intervening claims. 

The following is a statement of reasons for the indication of allowable subject 
matter: 

As to claims 9-1 1 and 22-24, the prior art of record Heistermann et al. (U.S. 
Patent No. 6,477,701 and Heistermann hereinafter) does not disclose, teach or suggest 
the claimed limitations of (in combination with all other features in the claims), mapping 
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attributes between the object and the serialized object; and storing serialized attribute 
values from the data stream in the object. 

The closest prior arts fail to anticipate or render Applicant's limitations above 
obvious. 

Conclusion 

9. THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded 
of the extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 



Points of Contact 

1 0. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Apu M. Mofiz whose telephone number is (571 ) 272- 
4080. The examiner can normally be reached on Monday - Thursday 8:00 A.M. to 4:30 
P.M. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Dov Popovici can be reached at (571) 272-4083. The fax numbers for the 
group is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application should 
be directed to the Group receptionist whose telephone number is (703) 305-9600. 
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